Add SIG Release charter #2919
Add SIG Release charter #2919
Conversation
Signed-off-by: Stephen Augustus <foo@agst.us>
k8s-ci-robot
added
size/M
k8s-ci-robot
added
the
sig/release
|
/hold |
k8s-ci-robot
added
the
do-not-merge/hold
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: calebamiles The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
| - SIG Release Members may override the majority decision of SIG Chairs by a supermajority (60%) | ||
|
|
||
| Additional requirements: | ||
| - KEP must establish subproject chairs |
| - Code branches | ||
| - Binary artifacts | ||
| - Release notes | ||
| - Continually improving release and development processes |
There was a problem hiding this comment.
Are we still talking about Kubernetes releases here, or have we switched gears to releases of all Kubernetes subprojects?
| - Defining and staffing release roles to manage the resolution of release blocking criteria | ||
| - Defining and driving development processes (e.g. merge queues, cherrypicks) and release processes | ||
| (e.g. burndown meetings, cutting beta releases) with the intent of meeting the release schedule | ||
| - Managing the creation of release specific artifacts, including: |
There was a problem hiding this comment.
I know this is a bit tangled up with SIG Architecture if they are the owners of "what is Kubernetes" but... which artifacts? Or put another way, which subprojects are in-scope vs. out-of-scope?
Maybe today's answer is "everything in k/k"? There are specific subprojects that live in there that already are (client-go) or may soon be (kubeadm) released on a different cadence. We also want to consider what this looks like with things like out-of-tree cloud provider and cluster api provider subprojects.
| - Serve as a tightly integrated partner with other SIGs to empower SIGs to integrate their repositories into the release process | ||
|
|
||
| ### In scope | ||
|
|
There was a problem hiding this comment.
Typically I would expect to see Code and Binaries enumerated here. Going by sigs.yaml you apparently own hyperkube, anago, and docs for the release process.
- Do you own package definitions that would be used to build .deb's, .rpm's or other packages, or are those considered downstream?
- Do you own any of the files involved in building kubernetes? Things like k/k/build/ or k/k's Makefiles?
- Do you own any jobs related to continuously building kubernetes, or are you solely responsible for manually produced builds?
| - All SIG Release top-level subproject OWNERS files | ||
| - All documented former Release Team members holding Lead roles e.g., Enhancements Lead, Patch Release Team | ||
|
|
||
| Subproject `approvers` and incoming Release Team Leads should ensure that new members are added to the `sig-release` GitHub team. |
| - Facilitating release retrospectives | ||
| - Collaborating with downstream communities which build artifacts from Kubernetes releases | ||
|
|
||
| ### Out of scope |
There was a problem hiding this comment.
As above, I think you're missing explicit details of which repos or subprojects you don't support. For example I doubt any repo in kubernetes-csi or kubernetes-client falls under your purview today
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
@spiffxp -- Thanks for your review! I'm going to opt to merge and iterate here, as I think everything will be better defined once we work through the KEPs for the individual subprojects. We'll take everything you mentioned as AIs. /hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
Moved over from kubernetes/sig-release#348.
This charter has already been approved by @jdumars @calebamiles @tpepper and @timothysc.
(Assigning Aaron for final Steering approval)
/assign @spiffxp
Signed-off-by: Stephen Augustus foo@agst.us